home *** CD-ROM | disk | FTP | other *** search
/ Columbia Kermit / kermit.zip / newsgroups / misc.19970326-19970626 / 000020_news@columbia.edu _Sun Mar 30 13:17:52 1997.msg < prev    next >
Internet Message Format  |  2020-01-01  |  4KB

  1. Return-Path: <news@columbia.edu>
  2. Received: from newsmaster.cc.columbia.edu (newsmaster.cc.columbia.edu [128.59.35.30])
  3.     by watsun.cc.columbia.edu (8.8.5/8.8.5) with ESMTP id NAA07630
  4.     for <kermit.misc@watsun.cc.columbia.edu>; Sun, 30 Mar 1997 13:17:51 -0500 (EST)
  5. Received: (from news@localhost)
  6.     by newsmaster.cc.columbia.edu (8.8.5/8.8.5) id NAA00693
  7.     for kermit.misc@watsun; Sun, 30 Mar 1997 13:17:50 -0500 (EST)
  8. Path: news.columbia.edu!panix!news.eecs.umich.edu!news.radio.cz!newsbastard.radio.cz!news.radio.cz!CESspool!hammer.uoregon.edu!news.mathworks.com!howland.erols.net!cs.utexas.edu!news.cs.utah.edu!cc.usu.edu!jrd
  9. From: jrd@cc.usu.edu (Joe Doupnik)
  10. Newsgroups: comp.os.ms-windows.nt.misc,comp.protocols.kermit.misc
  11. Subject: Re: K95 Kermit flickers on Key Input in NT4.0
  12. Message-ID: <1997Mar30.104144.96113@cc.usu.edu>
  13. Date: 30 Mar 97 10:41:44 MDT
  14. References: <5hbo8d$lbi$1@news.impulse.net> <5hh6tb$982$1@apakabar.cc.columbia.edu>
  15. Organization: Utah State University
  16. Lines: 51
  17. Xref: news.columbia.edu comp.os.ms-windows.nt.misc:185311 comp.protocols.kermit.misc:6835
  18.  
  19. In article <5hh6tb$982$1@apakabar.cc.columbia.edu>, fdc@watsun.cc.columbia.edu (Frank da Cruz) writes:
  20. > More on this...
  21. > In article <5hh2ug$e5p$1@news.impulse.net>,
  22. > Stephen Au <stephen@arktel.com> wrote:
  23. > : >Frank da Cruz wrote:
  24. > : >>In article <5hbo8d$lbi$1@news.impulse.net>,
  25. > : >>Stephen Au <stephen@arktel.com> wrote:
  26. > : >>: 
  27. > : >>: I have been using K95 under WIN95 for sometime and it works OK (slow)
  28. > : >>:
  29. > : >>Slow compared to what?
  30. > : 
  31. > : Slow in couple respects, with serial connections @ 9600/19200 bps.
  32. > : 
  33. > : #1. Compared to real-life WYSE-60 terminals at 9600/19200 bps. 
  34. > :
  35. > Of course.  A terminal is a special-purpose device that does nothing but
  36. > "terminal emulation" -- routing incoming bytes directly to the screen
  37. > (possibly after interpreting some escape sequences using some (usually) very
  38. > tight machine code in its PROM), and routing keystrokes directly to the serial
  39. > port -- often using two separate dedicated processors.
  40. > : I grant that this "perception" of "slowness" is largely due to the pausing
  41. > : between screen updates because I timed the output with a stop watch and the
  42. > : result is similar.  But on keyboard input, there is just this perceptible
  43. > : delay between a key is depressed and a character appearing on the screen.
  44. > : And it slows down productivity.
  45. > : 
  46. > This does not happen to everybody.  Most people see an instantaneous response.
  47. > When there *is* a delay, it is caused by Windows' scheduling of Kermit 95's
  48. > threads.
  49. ----------
  50.     Snipping out lots of neat technical discussion.
  51.     Just for perspective, MSK version 3.15 beta has a time of day clock
  52. presentation on the terminal emulation status line. We found that simply
  53. asking DOS for the current time of day, while waiting for bytes to arrive,
  54. was enough to cause Win95 to shakily refresh the screen. Most annoying. I
  55. had to add code to turn off the clock when MSK is run in Windows.
  56.     What this says is screen updating and sundry within Win95 is very
  57. nervous. A screen refresh seems to be triggered by the slightest thing,
  58. and that of course takes cpu time and tends to annoy users.
  59.     Now add back the many threads of Kermit95 with their systems calls,
  60. and guess how Win95 can be frightened into updating the screen on every little
  61. happenstance.
  62.     A lesson is comms programs should avoid the "o/s" as much as possible
  63. and do all the work themselves, if allowed to come that close to the comms
  64. machinery. MSK does this, being a DOS style program, but Windows programs
  65. are not allowed to unless they are a VxD or similar. 
  66.     Joe D.
  67.